Release 10.1A: OpenEdge Data Management:
DataServer for ORACLE
Sample Queries
This appendix contains sample queries and the information that the DataServer provides when you specify the
QUERY-TUNING(DEBUG SQL)option. In each case, notes explain the DataServer and cursor behavior. The numbers in angle brackets (<n>) indicate cursor handles for SQL statements.Query 1
<2> The DataServer uses the cursor to compare schema information and fetch column values.
<3,4> The
WHEREclause generated by the DataServer positions the cursor after the row retrieved by the first use of cursor <2> to retrieveCUSTOMER 2.Query 2
<2> The DataServer uses the cursor to compare schema information and fetch column values.
<2> The DataServer uses this cursor for customer 2.
<5> The
WHEREclause generated by the DataServer positions the cursor forcountry-postafterCUSTOMER2. TheORDERBYclause uses thePROGRESS_RECIDcolumn as the final component to guarantee unique ordering.Query 3
<2> The DataServer uses the cursor to compare schema information and fetch column values.
<3> This cursor selects the
PROGRESS_RECIDcolumn for a particular row byCUST_NUM.Query 4
<2> The DataServer uses the cursor to compare schema information and fetch column values.
<3> The DataServer executes the
FINDFIRSTCUSTOMER.<4> The DataServer retrieves
CUSTOMER2.Query 5
<2> The DataServer uses the cursor to compare schema information. It does not fetch any column values.
<3> The single lookahead cursor selects columns directly. It ignores the field list because the
FOREACHloop defaults to aSHARE-LOCK. Also, sinceFOREACHloops do not guarantee order of retrieval, the DataServer has not added anORDERBYclause. The DataServer calledOCIStmtFetchto fetch an array of rows. The DataServer used the default cache-size of 8192. Since 472 bytes are required for each row, it used 8024 bytes of cache to fetch up to 17 rows each call. Processing the 85 rows in theCUSTOMERtable required a total of 5 array fetches.Query 6
<2> The DataServer uses the cursor to compare schema information. It does not fetch any column values.
<3> The single lookahead cursor selects columns directly. It selects all columns because the query does not contain a field list.
Query 7
<2> The DataServer uses the cursor to compare schema information. It does not fetch any column values.
<3> The cursor selects only the fields in the field-list. The default cache-size of 8192 is sufficient to hold 106 rows. A single fetch retrieves the entire
CUSTOMERtable.Query 8
<2> The DataServer uses the cursor to compare schema information and fetch column values.
<3> This is a standard cursor. The default cache size is 1024. Since the DataServer fetches only the
PROGRESS_RECIDcolumn, it requires only 4 bytes for each row. A single fetch retrieves all 85PROGRESS_RECIDvalues in theCUSTOMERtable.Query 9
<2> The DataServer uses the cursor to compare schema information and fetch column values.
<3> This is a standard cursor. Note that the advantage of using a field list is lost by not using a lookahead cursor. The DataServer uses the schema comparison cursor to retrieve column values by the
PROGRESS_RECIDcolumn. Only those fields mentioned in the field list are available to the client.Query 10
<2> The DataServer uses the cursor to compare schema information. It does not fetch any column values.
<3> The DataServer uses the cursor to compare schema information. It does not fetch any column values.
<4> The cursor is used to perform the join by the SQLDB. Since the query specifies
NO-LOCK, this cursor selects the fields in the field list in addition to those that the client requires (T0.PROGRESS_RECID,T1.PROGRESS_RECID,T1.CUST_NUM). With the default cache size of 8192, processing the entire join requires 3 array fetches.Query 11
<2> The DataServer uses the cursor to compare schema information. It does not fetch any column values.
<3> The DataServer uses the cursor to compare schema information. It does not fetch any column values. Note that because the
ORDER_table contains adate, the DataServer does not reuse this cursor to fetch column values.<4> The cursor is used to perform the join by the SQLDB. The join still requires a lookahead cursor.
<5> Since the query requests the
ORDER_row with aSHARE-LOCK, the DataServer must refetch eachORDER_row to get all the columns. If theORDER_table did not have a record identifier (PROGRESS_RECIDin this case), this query would fail. If you must retrieve theORDER_row with aSHARE-LOCK, removing the field list eliminates the need to refetch the row.Query 12
<2> The DataServer uses the cursor to compare schema information and fetch
CUSTOMERrows.<3> The DataServer uses the cursor to compare schema information. It does not fetch any column values. Note that because the
ORDER_table contains a date, the DataServer does not reuse this cursor to fetch column values.<4> The cursor is used to perform the join by the SQLDB. It uses a standard cursor for the join. Each row of the join requires 8 bytes of the cache because the join cursor fetches only the unique integer record identifiers.
<5> The DataServer uses this cursor to fetch
ORDER_rows by thePROGRESS_RECIDcolumn. It cannot use the schema comparison cursor (<39>) because the DataServer must perform aTO_CHARconversion on the date columns.Query 13
<2> The DataServer uses the cursor to compare schema information and fetch
CUSTOMERrows.<3> The DataServer uses the cursor to compare schema information. It does not fetch any column values. Note that because the
ORDER_table contains a date, the DataServer does not reuse this cursor to fetch column values.<4> The DataServer uses a lookahead cursor to select fields in the field list in addition to those required by the client.
<5> The lookahead cursor selects fields from the
ORDER_table that correspond to a particularCUSTOMERrow (WHERECUST_NUM=:1).
|
Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |